Concurrent requirements engineering with a UML subset based on component schema relationships

Classes The property isAbstract indicates that a given class specification cannot be instantiated directly. This construct mainly introduces a uniform treatment of related real-world things in problem analysis. According to our modelling experience, this adornment is often used when similar structural as well as behavioural features of classes are combined into a generalisation. The specialised classes directly represent real-world things in the application domain, while the generalisation expresses the similarity between them. It does not lead to instances of their own right, since there is no direct counterpart in reality. However, building abstract classes can be considered as design-related, since code sharing is the central concern for this activity. On the other hand, introducing abstract classes is one of the important assets of problem analysis. From an analysis perspective, concepts previously considered as independent will then be related to each other. Although this construct has a considerable significance in design, it is equally valid in problem analysis and therefore will be incorporated in component schemas. According to the Notation Guide [OMG97b], class names written in italics distinguish abstract classes from concrete ones. Aggregation versus Composition Unlike Generalization, the metamodel does not contain a direct counterpart for aggregation, i.e. a metaclass called aggregation. Furthermore, UML distinguishes in between two different forms of aggregation: aggregation and composition. While aggregation does not impose constraints on the life-time between whole and part, composition relationships express a coinciding life-time of both whole and part. In other words, parts in a composition have to be destroyed when the life-time of the whole ends. Furthermore, parts in a composition must not be shared, i.e. an instance of a part may not participate in several aggregates. Concrete life-time considerations with respect to whole and parts have to be ignored in requirements engineering. Composition in the Metamodel As mentioned above UML does not feature compositions as individual metaclasses. Furthermore, compositions are defined as adornments of metaclass AssociationEnd in terms of the property aggregation. The semantic document states: “When placed on a target end, specifies whether the target end is an aggregation with respect to the source end. Only one end can be an aggregation.” [OMG97a, p. 18] Figure 29 Different Notations for Compositions in UML However, this essential consistency constraint has not been covered in the wellformedness rules! This and other deficiencies have been discussed in detail in Ute Schirmer’s diploma thesis [Schi98]. Generally speaking, n-ary relationships and compositions are only distinguished by adornments on the AssociationEnds. Composition, like associations, may carry a unique name. The Notation Guide presents the following example for alternate visualisation of compositions with role Window Window Slider Header Panel scrollbar title body 2 1 1 scrollbar [2] : Slider title : Header body : Panel